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DETAILED ACTION 

1. Applicant's amendment dated May 6, 2009, responding to the Office action 
mailed February 6, 2009 provided in the rejection of claims 1 , 3-28, 30-36, 38, 40, 42, 
and 44, wherein claims 1 , 3, 7-10, 15, 20-23, 28, 30-32, 34-36, 38, 40, 42 and 44 have 
been amended, claims 46-55 have been newly added. 

Claims 1, 3-28, 30-36, 38, 40, 42, 44, and 46-55 remain pending in the 
application and which have been fully considered by the examiner. 

Applicant's arguments with respect to claims currently amended have been fully 
considered but are moot in view of the new grounds of rejection - see Lai - art made of record, 
as applied hereto. 

Further, Applicant's arguments with respect to prior art reference of Koch and 
APA (Applicant's Admitted Prior Art) have been fully considered but are not persuasive. 
Please see the section of "Response to Arguments" for details. 

2. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
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will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 
1 .136(a) will be calculated from the mailing date of the advisory action. In no event, however, 
will the statutory period for reply expire later than SIX MONTHS from the date of this final 
action. 



Claim Rejections - 35 USC § 103(a) 

The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 1 02 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1, 3-27, 36, 38, 40, 46-48, and 51-55 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Samo Zorc (Pub. No. US 2003/0167444 A1) (hereinafter 
'Zorc') in view of Michael Koch (Leverage legacy systems with a blend of XML, XSL, 
and Java®, October 6, 2000, JavaWorld.com - appeared on JavaWorld at 
<http://www.javaworld.com/javaworld/jw-10-2000/jw-1006-legacy.html>) (hereinafter 
'Koch'), Ray Y. Lai (Pub. No. US 2005/0044197 A1 ) (hereinafter 'Lai' - art made of 
record), and Applicant's admitted prior art wherein paragraph [0005] on page 3 is clearly 
admitted "to transfer a payload message directly between the program language and 
the OLTP language" disclosed in the instant application (hereinafter 'APA') 



4. As to claim 1 (Currently Amended), Zorc discloses a method of processing 
messages comprising: 
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• receiving a markup language document describing a message (e.g., Fig. 2, 
XML Message Definition; [0009] - ... directly from an XML schema message 
definition ): and 

• compiling the automatically-generated source code (e.g., [0009] - ... a 
mechanism is provided for automatically generating a conversion module 
directly from an XML schema message definition : [0010]; [0026] - ... a 
compilation mechanism for automatically generating the conversion module 
...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023] - [0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the markup language document being compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., P. 5, Sec. of 
"Conclusion" - XML , XSL, and Java ® work hand in hand to solve the complex 
problem of mainframe transaction access . . . XML allows us to describe the 
structure of the COBOL transaction (compliant with message rules associated 
with an OLTP language), providing directions to the Java® engine on how to 
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build the request or parse the response . . . ; P. 3, last 5 th Line - Apply the 
metadata and rules to the message); 
• receiving a template for code in a program language, the template describing a 
data format for the message in a program language (e.g., P. 2, Sec. of " XSL 
Style ", 1 st Para - ... use the XSL language for manipulating XML from one 
structure into another : 2 nd Para - ... use XSL to format an incoming document 
structure to the name/value-pair structured described above, which the Java 
code process into the COBOL structure. XSL will also format the data returned 
from the legacy system - once the Java code transforms it back into XML ...) 
Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating the Koch's system which offers significant advantages 
of combining XML, XSL, and Java to interface with mainframe system (e.g., P. 1, 2 nd 
Para) and using XSL language for manipulating XML format one structure into another, 
transforming XML into other XML document structure (e.g., Sec. of 'XSL Style', 2 nd 
Para), using Xerces parser for easy XML manipulation within Java (e.g., 3 rd Para) and 
further using XML to describe the structure of the COBOL transaction, providing 
directions to the Java® engine on how to build the request or parse the response as 
once suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 
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Furthermore, Koch discloses combining XML, XSL, and Java to interface with 
mainframe system (e.g., P. 1, 2 nd Para) and using XSL language for manipulating XML 
format one structure into another, transforming XML into other XML document structure 
(e.g., Sec. of 'XSL Style', 2 nd Para), using Xerces parser for easy XML manipulation 
within Java (e.g., 3 rd Para) but Zorc and Koch do not explicitly disclose other limitations 
stated below. 

However, in an analogous art of Structured Methodology and Design Patterns for 
Web Services, Lai discloses: 

• automatically generating source code in the program language from the 
markup language document and the template, the automatically-generated 
source code depending on both the markup language document and the 
template, and configured to transform a payload message directly between 
the target program language data format and an online transaction 
processing (OLTP) language message format when compiled and executed 
(e.g., [0038] - ... JAXB creates an XML-to-Java binding schema (XJS) which 
maps XML elements to Java objects , and stores it in XJS files ... compile 
them with a schema compiler call xjc and output the source code to a set of 
Java classes ... reads in a DTD and a XJS binding schema, and generates a 
set of Java source files ...; [0039] - ... compile the Java source files into Java 
classes for execution. This can potentially reduce some coding effort ... Using 
JAXB to bind an XML Schema to the Java data structure , developers can 
probably write less program code using an XML parser to transform XML 
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content into Java data objects. This is a considerable benefit to the 
productivity) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Lai into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that it would further enhance the Zorc-Koch's system by taking, 
advancing and/or incorporating the Lai's system which offers significant advantages for 
providing a mechanism for designing and implementing application solutions that may 
include mainframe and legacy systems interoperability and cross-enterprise integration 
as once suggested by Lai (e.g., [0059]) 

Lastly, Lai discloses using JAXB to bind an XML Schema to the Java data 
structure, developers can probably write less program code using an XML parser to 
transform XML content into Java data objects; this is a considerable benefit to the 
productivity (e.g., [0039]) but Zorc, Koch, and Lai do not explicitly disclose the 
limitations stated below. 

However, APA discloses using the compiled automatically-generated source 
code to transform the payload message directly between the target program language 
data format and the online transaction processing (OLTP) language message format 
(e.g., [0005] - ... a message parser receives a message in either the program language 
or the OLTP language and uses the compiled source code to transform the message 
between the program language and the OLTP language NOTE: using JAXB to bind 
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an XML Schema to the Java data structure (automatically-generated source code) and 
this is a considerable benefit to the productivity based Lai's reference) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch-Lai's 
system to further provide the limitations stated above in the Zorc-Koch-Lai system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

5. As to claim 3 (Original) (incorporating the rejection in claim 1), Koch discloses 
the method wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "The versatile XML, 3 rd Para - Using XML, you can now 
implement that copybook metadata to generate your copybook markup language; 
Below, this short, simplistic example of an XML document containing our COBOL 
program's metadata retrieves a name when given a social security number) 

6. As to claim 4 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the message is a request message from an application to an OLTP 
host (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing message 
structure", "incoming message structure") 

7. As to claim 5 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the message is a response message from an OLTP host to an 
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application (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing 
message structure", "incoming message structure") 

8. As to claim 6 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the markup language is an extensible markup language (e.g., Sec. 
of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface) 

9. As to claim 7 (Currently Amended) (incorporating the rejection in claim 2), Koch 
discloses the method wherein the template comprises the stylesheet data (e.g., P. 2, 
Sec. of "XSL Style", 2 nd Para - ... use XSL to format an incoming document structure to 
the name/value-pair structure ... which the Java® code processes into the COBOL 
structure . XSL will also format the data returned from the legacy system ... Java code 
transforms it back into XML ...) 

10. As to claim 8 (Currently Amended) (incorporating the rejection in claim 7), Koch 
discloses the method further including using a stylesheet parser (e.g., P. 2, Sec. of " XSL 
Style ". 1 st Para - ... use the XSL language for manipulating XML from one structure into 
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another : 2 nd Para - . . . use XSL to format an incoming document structure to the 
name/value-pair structured described above, which the Java code process into the 
COBOL structure. XSL will also format the data returned from the legacy system - once 

the Java code transforms it back into XMI ) and Koch further discloses automatically 

generating the source code (e.g., [0038] - ... JAXB creates an XML-to-Java binding 
schema (XJS) which maps XML elements to Java objects , and stores it in XJS files ... 
compile them with a schema compiler call xjc and output the source code to a set of 
Java classes ... reads in a DTD and a XJS binding schema, and generates a set of 
Java source files [0039] - ... compile the Java source files into Java classes for 
execution. This can potentially reduce some coding effort ... Using JAXB to bind an 
XML Schema to the Java data structure , developers can probably write less program 
code using an XML parser to transform XML content into Java data objects. This is a 
considerable benefit to the productivity) 

11. As to claim 9 (Currently Amended) (incorporating the rejection in claim 1), Zorc 
discloses the method further including receiving and compiling a plurality of markup 
language documents for a plurality of message types and generating source code to 
convert messages of the plurality of message types between the OLTP language and 
the target language (e.g., [0009] - ... a mechanism is provided for automatically 
generating a conversion module directly from an XML schema message definition : 
[0010]; [0026] - ... a compilation mechanism for automatically generating the conversion 
module ...) 
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12. As to claim 10 (Currently Amended) (incorporating the rejection in claim 1), Zorc 
discloses the method wherein the target language is an object-oriented program 
language (e.g., [0023] - ... for generating or receiving object-oriented code (e.g., Java® 
objects)) 

13. As to claim 11 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method further including: 

• receiving one or more name-value pairs for the message according to the 
object- oriented program language (e.g., P. 5, 1 st bullet - since XSL is applied 
to the incoming document as well as the outgoing document, the Java engine, 
once written, is insulated from changes in the incoming message structure; 
the entire DTD, or schema, of the incoming message could be changed 
completely; a programmer would only have to modify the XSL within this 
framework that styles the document into your name/value-pair format; 1 st Para 
[after program listing] - essentially, the code matches the fields with value 
from the array and creates name/value pairs that are suitable for simplistic 
XML document); 

• generating a byte array according to the OLTP language; and transmitting the 
byte array to an application (e.g., 1 st Para [after program listing] - data 
manipulation transforms the response from a byte array or similar structure 
into an XML document; essentially, the code matches the fields with value 
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from the array and creates name/value pairs that are suitable for simplistic 
XML document). 

14. As to claim 12 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method further including: receiving a byte array for the message according to the 
OLTP language; generating one or more name-value pairs according to the object- 
oriented program language; and transmitting the name-value pairs to an application 
(e.g., P. 5, 1 st bullet - since XSL is applied to the incoming document as well as the 
outgoing document, the Java engine, once written, is insulated from changes in the 
incoming message structure; the entire DTD, or schema, of the incoming message 
could be changed completely; a programmer would only have to modify the XSL within 
this framework that styles the document into your name/value-pair format; 1 st Para [after 
program listing] - essentially, the code matches the fields with value from the array and 
creates name/value pairs that are suitable for simplistic XML document) 

15. As to claim 13 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method wherein the object-oriented program language is a Java language (e.g., 
Sec. of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - 
XML describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, which 
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circumvents the frustrations and problems that arise from working with an extract file or 
batch interface) 

16. As to claim 14 (Original) (incorporating the rejection in claim 1 ), APA discloses 
the method wherein the OLTP language is a gaming system language (e.g., [0003] 
The OLTP host is responsible for managing the particular game being played ...) 

1 7. As to claim 1 5 (Currently Amended), Zorc discloses a method of generating 
source code comprising: 

• receiving a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] directly from an XML schema message definition ) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• receiving a template for code in a program language, the template describing a 
data format in a target program language for a message (e.g., P. 2, Sec. of " XSL 
Style ", 1 st Para - ... use the XSL language for manipulating XML from one 
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structure into another : 2 nd Para - ... use XSL to format an incoming document 
structure to the name/value-pair structured described above, which the Java 
code process into the COBOL structure. XSL will also format the data returned 

from the legacy system - once the Java code transforms it back into XMI ); 

and 

• the markup language document being compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., P. 5, Sec. of 
"Conclusion" - XML , XSL, and Java ® work hand in hand to solve the complex 
problem of mainframe transaction access . . . XML allows us to describe the 
structure of the COBOL transaction (compliant with message rules associated 
with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response . . . ; P. 3, last 5 th Line - Apply the 
metadata and rules to the message) 
Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract), but does not 
explicitly disclose other limitations stated below in the Zorc system. 

Therefore, it would have been obvious to one of ordinary skill in the art, at the time 
the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages of 
combining XML, XSL, and Java to interface with mainframe system (e.g., P. 1, 2 nd Para) 
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and using XSL language for manipulating XML format one structure into another, 
transforming XML into other XML document structure (e.g., Sec. of 'XSL Style', 2 nd 
Para), using Xerces parser for easy XML manipulation within Java (e.g., 3 rd Para) and 
further using XML to describe the structure of the COBOL transaction, providing 
directions to the Java® engine on how to build the request or parse the response as 
once suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses combining XML, XSL, and Java to interface with 
mainframe system (e.g., P. 1, 2 nd Para) and using XSL language for manipulating XML 
format one structure into another, transforming XML into other XML document structure 
(e.g., Sec. of 'XSL Style', 2 nd Para), using Xerces parser for easy XML manipulation 
within Java (e.g., 3 rd Para) but Zorc and Koch do not explicitly disclose other limitations 
stated below. 

However, in an analogous art of Structured Methodology and Design Patterns for 
Web Services, Lai discloses: 

• automatically generating a source code based on the markup language 
document and the template, the source code depending on both the markup 
language document and the template (e.g., [0038] - ... JAXB creates an XML-to- 
Java binding schema (XJS) which maps XML elements to Java objects , and 
stores it in XJS files ... compile them with a schema compiler call xjc and output 
the source code to a set of Java classes ... reads in a DTD and a XJS binding 
schema, and generates a set of Java source files ...; [0039] - ... compile the 
Java source files into Java classes for execution. This can potentially reduce 
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some coding effort ... Using JAXB to bind an XML Schema to the Java data 
structure , developers can probably write less program code using an XML parser 
to transform XML content into Java data objects. This is a considerable benefit to 
the productivity) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the time 
the invention was made to combine the teachings of Lai into the Zorc-Koch's system to 
further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that it would further enhance the Zorc-Koch's system by taking, 
advancing and/or incorporating the Lai's system which offers significant advantages for 
providing a mechanism for designing and implementing application solutions that may 
include mainframe and legacy systems interoperability and cross-enterprise integration 
as once suggested by Lai (e.g., [0059]) 

Lastly, Lai discloses using JAXB to bind an XML Schema to the Java data structure, 
developers can probably write less program code using an XML parser to transform 
XML content into Java data objects; this is a considerable benefit to the productivity 
(e.g., [0039]) but Zorc, Koch, and Lai do not explicitly disclose the limitations stated 
below. 

However, APA discloses enabling transformation of a payload message directly 
between the target program language data format and an OLTP language message 
format (e.g., [0005] - ... a message parser receives a message in either the program 
language or the OLTP language and uses the compiled source code to transform the 
message between the program language and the OLTP language ...; NOTE: using 
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JAXB to bind an XML Schema to the Java data structure (automatically-generated 
source code) and this is a considerable benefit to the productivity based Lai's reference) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch-Lai's 
system to further provide other limitations stated above in the Zorc-Koch-Lai system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

18. As to claim 16 (Original) (incorporating the rejection in claim 15), Koch discloses 
the method wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2 nd Para - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to encapsulate 
it with a few simple classes; You will then leverage a host of legacy system transactions 
written decades ago and development becomes easier; In addition, the solution, you 
employ is realtime, which circumvents the frustrations and problems that arise from 
working with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, 
and Java work hand i hand to solve the complex problem of mainframe transaction 
access; Implementing XSL styling creates supplementary layers in the framework that 
allow the solution to configure changes from the application server or the mainframe 
programs without recompiling the Java code that performs the mapping; XML allows us 
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to describe the structure of the COBOL transactions, providing directions to the Java® 
engine on how to build the request or parse the response) 

19. As to claim 17 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the message is a request message from an application to an OLTP 
host (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing message 
structure", "incoming message structure"). 

20. As to claim 18 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the message is a response message from an OLTP host to an 
application (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing 
message structure", "incoming message structure") 

21 . As to claim 19 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the markup language is an extensible markup language (e.g., Sec. 
of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface) 
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22. As to claim 20 (Currently Amended) (incorporating the rejection in claim 15), 
Koch discloses the method wherein the template comprises stylesheet data (e.g., P. 2, 
Sec. of " XSL Style ", 1 st Para - ... use the XSL language for manipulating XML from one 
structure into another : 2 nd Para - ... use XSL to format an incoming document structure 
to the name/value-pair structured described above, which the Java code process into 
the COBOL structure. XSL will also format the data returned from the legacy system - 
once the Java code transforms it back into XML ...) 

23. As to claim 21 (Currently Amended) (incorporating the rejection in claim 20), 
please refer to claim 8 above, accordingly. 

24. As to claim 22 (Currently Amended) (incorporating the rejection in claim 15), 
please refer to claim 9 above, accordingly. 

25. As to claim 23 (Currently Amended), Zorc discloses a method of processing 
messages comprising: 

• receiving one or more extensible markup language (XML) documents (e.g., 
Fig. 2, XML Message Definition; [0009] - ... directly from an XML schema 
message definition ): 

• compiling the source code (e.g., [0009] - ... a mechanism is provided for 
automatically generating a conversion module directly from an XML schema 
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message definition : [0010]; [0026] - ... a compilation mechanism for 
automatically generating the conversion module ...); 

• repeating the receiving and compiling of XML documents and the compiling of 
source code for a plurality of message types (e.g., Fig. 3, element 314 - 
Message Definition) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023] through [0025]; [0098]), but does not explicitly disclose other limitations 
stated below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the XML documents being compliant with message rules associated with an 
online transaction processing (OLTP) language and the message rules 
defining markup tags for describing components of a message (e.g., P. 5, 
Sec. of "Conclusion" - XML , XSL, and Java ® work hand in hand to solve the 
complex problem of mainframe transaction access ... XML allows us to 
describe the structure of the COBOL transaction (compliant with message 
rules associated with an OLTP language), providing directions to the Java® 
engine on how to build the request or parse the response ...; P. 3, last 5 th 
Line - Apply the metadata and rules to the message); and 
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• the stylesheet data describing a data format for the message in a target 
program language (e.g., P. 2, Sec. of " XSL Style ", 1 st Para - ... use the XSL 
language for manipulating XML from one structure into another : 2 nd Para - ... 
use XSL to format an incoming document structure to the name/value-pair 
structured described above, which the Java code process into the COBOL 
structure. XSL will also format the data returned from the legacy system - 

once the Java code transforms it back into XMI ) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages of 
combining XML, XSL, and Java to interface with mainframe system (e.g., P. 1, 2 nd Para) 
and using XSL language for manipulating XML format one structure into another, 
transforming XML into other XML document structure (e.g., Sec. of 'XSL Style', 2 nd 
Para), using Xerces parser for easy XML manipulation within Java (e.g., 3 rd Para) and 
further using XML to describe the structure of the COBOL transaction, providing 
directions to the Java® engine on how to build the request or parse the response as 
once suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses combining XML, XSL, and Java to interface with 
mainframe system (e.g., P. 1, 2 nd Para) and using XSL language for manipulating XML 
format one structure into another, transforming XML into other XML document structure 
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(e.g., Sec. of 'XSL Style', 2 nd Para), using Xerces parser for easy XML manipulation 
within Java (e.g., 3 rd Para) but Zorc and Koch do not explicitly disclose other limitations 
stated below. 

However, in an analogous art of Structured Methodology and Design Patterns for 
Web Services, Lai discloses: 

• automatically compiling the XML documents into source code in an object- 
oriented program language based on stylesheet data (e.g., [0038] - ... JAXB 
creates an XML-to-Java binding schema (XJS) which maps XML elements to 
Java objects , and stores it in XJS files ... compile them with a schema 
compiler call xjc and output the source code to a set of Java classes ... reads 
in a DTD and a XJS binding schema, and generates a set of Java source files 

[0039] compile the Java source files into Java classes for execution. 
This can potentially reduce some coding effort ... Using JAXB to bind an XML 
Schema to the Java data structure , developers can probably write less 
program code using an XML parser to transform XML content into Java data 
objects. This is a considerable benefit to the productivity; NOTE: Koch 
teaches using stylesheet data (e.g., P. 2, Sec. of " XSL Style ", 1 st Para - 2 nd 
Para); 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Lai into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 
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The motivation is that it would further enhance the Zorc-Koch's system by taking, 
advancing and/or incorporating the Lai's system which offers significant advantages for 
providing a mechanism for designing and implementing application solutions that may 
include mainframe and legacy systems interoperability and cross-enterprise integration 
as once suggested by Lai (e.g., [0059]) 

Lastly, Lai discloses using JAXB to bind an XML Schema to the Java data 
structure, developers can probably write less program code using an XML parser to 
transform XML content into Java data objects; this is a considerable benefit to the 
productivity (e.g., [0039]) but Zorc, Koch, and Lai do not explicitly disclose the 
limitations stated below. 

However, APA discloses the source code configured, when compiled and 
executed, to transform the message directly between the target program language data 
format and an OLTP language message format; using the compiled source code to 
transform a payload message directly between the target language data format and the 
OLTP language message format (e.g., [0005] - ... a message parser receives a 
message in either the program language or the OLTP language and uses the compiled 
source code to transform the message between the program language and the OLTP 
language ...); and the OLTP language being a gaming system language (e.g., [0003] - 
... The OLTP host is responsible for managing the particular game being played ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch-Lai's 
system to further provide other limitations stated above in the Zorc-Koch-Lai system. 
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The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

26. As to claim 24 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including using a stylesheet parser to compile the XML documents 
(e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL to format an incoming document 
structure to the name/value-pair structure ... which the Java® code processes into the 
COBOL structure . XSL will also format the data returned from the legacy system ... 
Java code transforms it back into XML . . . ) 

27. As to claim 25 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including: 

• receiving one or more name-value pairs for the message according to the 
program language (e.g., P. 5, 1 st bullet - since XSL is applied to the incoming 
document as well as the outgoing document, the Java engine, once written, is 
insulated from changes in the incoming message structure; the entire DTD, or 
schema, of the incoming message could be changed completely; a programmer 
would only have to modify the XSL within this framework that styles the 
document into your name/value-pair format; 1 st Para [after program listing] - 
essentially, the code matches the fields with value from the array and creates 
name/value pairs that are suitable for simplistic XML document); 
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• generating a byte array according to the OLTP language; and transmitting the 
byte array to an application (e.g., 1 st Para [after program listing] - data 
manipulation transforms the response from a byte array or similar structure into 
an XML document; essentially, the code matches the fields with value from the 
array and creates name/value pairs that are suitable for simplistic XML 
document) 



28. As to claim 26 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including: 

• receiving a byte array for the message according to the OLTP language (e.g., 
1 st Para [after program listing] - data manipulation transforms the response 
from a byte array or similar structure into an XML document; essentially, the 
code matches the fields with value from the array and creates name/value 
pairs that are suitable for simplistic XML document); 

• generating one or more name-value pairs according to the program language; 
and transmitting the name-value pairs to an application (e.g., P. 5, 1 st bullet - 
since XSL is applied to the incoming document as well as the outgoing 
document, the Java engine, once written, is insulated from changes in the 
incoming message structure; the entire DTD, or schema, of the incoming 
message could be changed completely; a programmer would only have to 
modify the XSL within this framework that styles the document into your 
name/value-pair format; 1 st Para [after program listing] - essentially, the code 
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matches the fields with value from the array and creates name/value pairs 
that are suitable for simplistic XML document) 



29. As to claim 27 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method wherein the object-oriented program language is a Java language (e.g., 
Sec. of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - 
XML describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, which 
circumvents the frustrations and problems that arise from working with an extract file or 
batch interface) 



30. As to claim 36 (Currently Amended) (incorporating the rejection in claim 1 ), APA 
discloses the method further comprising: 

• providing an online gaming system by an OTLP host which uses the OLTP 
language, wherein the online gaming system processes wagering-related 
transactions (e.g., [0003] - The OLTP host is responsible for managing the 
particular game being played ...); and 

• providing an application at a consumer location which uses the target program 
language, wherein the application provides access to the wagering-related 
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transactions for the consumer (e.g., [0005] - ... to transform the message 
between the program language and the OLTP language ...); 
• wherein the payload message is part of at least one of the wagering-related 
transactions and comprises at least one of: a request to place an online wager, 
or a response to the request to place the online wager (e.g., [0005] - ... 
LottoWagerRequest message ... WagerResponse message ...) 

31 . As to claim 38 (Currently Amended) (incorporating the rejection in claim 15), 
refer to claim 36 above accordingly. 

32. As to claim 40 (Currently Amended) (incorporating the rejection in claim 23), 
refer to claim 36 above accordingly. 

33. As to claim 46 (New) (incorporating the rejection in claim 1), Koch discloses the 
method wherein the program language is the target program language (e.g., P. 1 , 2nd 
Para - ... Use Java to encapsulate it with a few simple classes ...) 

34. As to claim 47 (New) (incorporating the rejection in claim 15), please refer to 
claim 46 above, accordingly. 

35. As to claim 48 (New) (incorporating the rejection in claim 23), please refer to 
claim 46 above, accordingly. 



Application/Control Number: 10/681,057 
Art Unit: 2192 



Page 28 



36. As to claim 51 (New) (incorporating the rejection in claim 1), APA discloses the 
method wherein the automatically-generated source code is further configured to 
transform the first payload message directly from the target program language data 
format to the online transaction processing (OLTP) language message format, and to 
transform a second payload message directly from the OLTP language message format 
to the target program language data format (e.g., [0005] - ... a message parser receives 
a message in either the program language or the OLTP language and uses the 
compiled source code to transform the message between the program language and 
the OLTP language NOTE: using JAXB to bind an XML Schema to the Java data 
structure (automatically-generated source code) and this is a considerable benefit to the 
productivity based Lai's reference) 

37. As to claim 52 (New) (incorporating the rejection in claim 15), please refer to 
claim 51 above, accordingly. 

38. As to claim 53 (New) (incorporating the rejection in claim 23), please refer to 
claim 51 above, accordingly. 

39. As to claim 54 (New) (incorporating the rejection in claim 28), please refer to 
claim 51 above, accordingly. 
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40. As to claim 55 (New) (incorporating the rejection in claim 32), please refer to 
claim 51 above, accordingly. 

41 . Claims 28, 30-35, 42, 44, and 49-50 are rejected under 35 U.S.C. 103(a) as 
being unpatentable overZorc, Koch, and APA 

42. As to claim 28 (Currently Amended), Zorc discloses a message processing 
apparatus comprising: 

an application server including 

• a development module stored on the application server, the development module 
to receive a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] directly from an XML schema message definition ) and automatically 
generate a source code in a program language (e.g., [0010] - ... automatically 
generating source code based on a mark-up language message definition ...), 
the source code depending on both the markup language document ; and 

• a program compiler stored on the application server, the program compiler 
configured to compile the source code (e.g., [0009] - ... a mechanism is provided 
for automatically generating a conversion module directly from an XML schema 
message definition : [0010]; [0026] - ... a compilation mechanism for 
automatically generating the conversion module ...); 

• configured to generate a source in the program language, the source code based 
on the markup language document and the template (e.g., [0010] - ... 
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automatically generating source code based on a mark-up language message 
definition ...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• a template for code in a program language, the template describing a message 
data format in a target program language (e.g., P. 2, Sec. of " XSL Style ". 1 st Para 
- . . . use the XSL language for manipulating XML from one structure into another : 
2 nd Para - . . . use XSL to format an incoming document structure to the 
name/value-pair structured described above, which the Java code process into 
the COBOL structure. XSL will also format the data returned from the legacy 
system - once the Java code transforms it back into XMI ); and 

• the markup language document to be compliant with message rules associated 
with the OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML , XSL, and Java ® 
work hand in hand to solve the complex problem of mainframe transaction 
access . . . XML allows us to describe the structure of the COBOL transaction 
(compliant with message rules associated with an OLTP language), providing 
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directions to the Java® engine on how to build the request or parse the response 
...; P. 3, last 5 th Line - Apply the metadata and rules to the message) 
Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages of 
combining XML, XSL, and Java to interface with mainframe system (e.g., P. 1, 2 nd Para) 
and using XSL language for manipulating XML format one structure into another, 
transforming XML into other XML document structure (e.g., Sec. of 'XSL Style', 2 nd 
Para), using Xerces parser for easy XML manipulation within Java (e.g., 3 rd Para) and 
further using XML to describe the structure of the COBOL transaction, providing 
directions to the Java® engine on how to build the request or parse the response as 
once suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses the source code configured to enable direct 
transformation of the payload message directly between the program language and the 
OLTP language; and the message parser stored on application server configured to 
transform a payload message between the target program language message data 
format and an online transaction processing (OLTP) language message data format 
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using the compiled source code (e.g., [0005] - ... a message parser receives a 
message in either the program language or the OLTP language and uses the compiled 
source code to transform the message between the program language and the OLTP 
language ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

43. As to claim 30 (Currently Amended) (incorporating the rejection in claim 28), 
Koch discloses the system wherein the message rules define markup tags for 
describing components of the message (e.g., Sec. of "Combine XML, XSL, and Java to 
interface with mainframe systems", 2 nd Para - XML describes the structure of the data 
you are sending; Add XSL to complete some simple transformations; Use Java® to 
encapsulate it with a few simple classes; You will then leverage a host of legacy system 
transactions written decades ago and development becomes easier; In addition, the 
solution, you employ is realtime, which circumvents the frustrations and problems that 
arise from working with an extract file or batch interface; Fig. 1 - Legacy transaction 
framework, elements of "Calling Application", "Java Engine", "Outgoing message 
structure", "Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - 
XML, XSL, and Java work hand i hand to solve the complex problem of mainframe 
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transaction access; Implementing XSL styling creates supplementary layers in the 
framework that allow the solution to configure changes from the application server or 
the mainframe programs without recompiling the Java code that performs the mapping; 
XML allows us to describe the structure of the COBOL transactions, providing directions 
to the Java® engine on how to build the request or parse the response) 

44. As to claim 31 (Currently Amended) (incorporating the rejection in claim 28), 
please refer to claim 8 above, accordingly. 

45. As to claim 32 (Currently Amended), Zorc discloses a machine readable 
medium comprising a set of stored instructions capable of being executed by a 
processor to: 

• receive a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] directly from an XML schema message definition ); and 

• automatically generate a source code based on the markup language document 
and the template (e.g., [0010] - ... automatically generating source code based 
on a mark-up language message definition ...); 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 



Application/Control Number: 1 0/681 ,057 Page 34 

Art Unit: 2192 

(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• receive a template for code in a program language, the template describing a 
data format in a target program language relating to a message (e.g., P. 2, Sec. 
of " XSL Style ", 1 st Para - . . . use the XSL language for manipulating XML from 
one structure into another ): and 

• the markup language document to be compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., Sec. of "Combine 
XML, XSL, and Java to interface with mainframe systems", 2 nd Para - XML 
describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; 
You will then leverage a host of legacy system transactions written decades ago 
and development becomes easier; In addition, the solution, you employ is 
realtime, which circumvents the frustrations and problems that arise from working 
with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - 
XML, XSL, and Java work hand in hand to solve the complex problem of 
mainframe transaction access; Implementing XSL styling creates supplementary 
layers in the framework that allow the solution to configure changes from the 
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application server or the mainframe programs without recompiling the Java code 
that performs the mapping; XML allows us to describe the structure of the 
COBOL transactions, providing directions to the Java® engine on how to build 
the request or parse the response) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages of 
combining XML, XSL, and Java to interface with mainframe system (e.g., P. 1, 2 nd Para) 
and using XSL language for manipulating XML format one structure into another, 
transforming XML into other XML document structure (e.g., Sec. of 'XSL Style', 2 nd 
Para), using Xerces parser for easy XML manipulation within Java (e.g., 3 rd Para) and 
further using XML to describe the structure of the COBOL transaction, providing 
directions to the Java® engine on how to build the request or parse the response as 
once suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses configured to transform payload message directly 
between the target program language data format and an OLTP language data format, 
when the source code is compiled and executed (e.g., [0005] - ... a message parser 
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receives a message in either the program language or the OLTP language and uses the 
compiled source code to transform the message between the program language and 
the OLTP language ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

46. As to claim 33 (Original) (incorporating the rejection in claim 32), Koch discloses 
the medium wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2 nd Para - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to encapsulate 
it with a few simple classes; You will then leverage a host of legacy system transactions 
written decades ago and development becomes easier; In addition, the solution, you 
employ is realtime, which circumvents the frustrations and problems that arise from 
working with an extract file or batch interface) 

47. As to claim 34 (Currently Amended) (incorporating the rejection in claim 32), 
Koch discloses the medium wherein the template comprises stylesheet data (e.g., P. 2, 
Sec. of " XSL Style ". 1 st Para - ... use the XSL language for manipulating XML from one 
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structure into another : 2 nd Para - ... use XSL to format an incoming document structure 
to the name/value-pair structured described above, which the Java code process into 
the COBOL structure. XSL will also format the data returned from the legacy system - 
once the Java code transforms it back into XMI ) 

48. As to claim 35 (Currently Amended) (incorporating the rejection in claim 32), 
Zorc discloses the medium wherein the instructions are further capable of being 
executed to receive a plurality of markup language documents for a plurality of message 
types and to generate source code for converting the plurality of message types 
between the OLTP language message format and the target language message format 
(e.g., [0009] - ... a mechanism is provided for automatically generating a conversion 
module directly from an XML schema message definition : [0010]; [0026] - ... a 
compilation mechanism for automatically generating the conversion module ...) 

49. As to claim 42 (Currently Amended) (incorporating the rejection in claim 28), 
refer to claim 36 above accordingly. 

50. As to claim 44 (Previously Presented) (incorporating the rejection in claim 32), 
refer to claim 36 above accordingly. 

51 . As to claim 49 (New) (incorporating the rejection in claim 28), please refer to 
claim 46 above, accordingly. 
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52. As to claim 50 (New) (incorporating the rejection in claim 32), please refer to 
claim 46 above, accordingly. 

Response to Arguments 

53. Applicant's arguments filed on May 6, 2009 have been fully considered but they 
are not persuasive. 

In the remarks, Applicant argues that, for examples: 

(A.1) Applicants do not agree or admit that Koch is a proper prior art reference (stated 
in 3 rd paragraph on page 12 in REMARKS) 

(A.2) Applicants do not agree or admit that any admission as to prior art was made, or 
that the material referred to as "Applicant's Admitted Prior Art" is prior art to the present 
application (stated in 4 th paragraph on page 12 in REMARKS) 

Examiner's response: 

(R.1) As per the argument one (A.1 ) above, MPEP 21 28 states " An electronic 

publication , including an on-line database or Internet publication , is 

considered to be a " printed publication " within the meaning of 35 U.S.C. 102(a) and (b) 

provided the publication was accessible to persons concerned with the art to which the 

document relates . See In re Wyer, 655 F.2d 221, 227, 210 USPQ 790, 

795 (CCPA 1981) ("Accordingly, whether information is printed, handwritten, or on 
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microfilm or a magnetic disc or tape, etc., the one who wishes to characterize the 
information, in whatever form it may be, as a printed publication' * * * should produce 
sufficient proof of its dissemination or that it has otherwise been available and 
accessible to persons concerned with the art to which the document relates and thus 
most likely to avail themselves of its contents.'" (citations omitted).). See also 
Amazon.com v. Barnesandnoble.com, 73 F. Supp. 2d 1228, 53 USPQ2d 1115, 1119 
(W.D. Wash. 1999) (Pages from a website were relied on by defendants as an 
anticipatory reference (to no avail), however status of the reference as prior art was not 
challenged.); In re Epstein, 32 F.3d 1559, 31 USPQ2d 1817 (Fed. Cir. 1994) (Database 
printouts of abstracts which were not themselves prior art publications were properly 
relied as providing evidence that the software products referenced therein were "first 
installed" or "released" more than one year prior to applicant's filing date.)." (stated in 
the section of 'Electronic Publications As Prior Art - with emphasis added) 

Koch's prior art reference was published by JavaWorld® dated October 6. 2000 . 
which is an electronic publication and publicly accessible via the following URL: 
<http://www.javaworld. com/javaworld/jw- 1 0-2000/jw- 1 006-legacy.html> 

Thus, Koch is qualified as a prior reference for the pending application. 

(R.2) As per the argument two (A. 2) above, the specification clearly admits " to transfer 
a payload message directly between the program language and the OLTP language " 
disclosed in the instant application (stated in paragraph [0005] in BACKGROUND 
section) Further, the specification states "Unfortunately, the manual labor associated 
with writing the source code all of the possible message types typically ... can have a 
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significant effort on the development. There is therefore a need to reduce the amount of 
time, labor and expense required to generate source that is used to transform 
messages between a program language and an OLTP language" (see paragraph [0006] 
- emphasis added) Thus, the major newly amended claim limitations try to cover this 
matter. 

Conclusion 

54. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ben C. Wang whose telephone number is 571-270- 
1240. The examiner can normally be reached on Monday - Friday, 8:00 a.m. - 5:00 
p.m., EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on 571-272-3695. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/Ben C Wang/ 
Ben C. Wang 
Examiner, Art Unit 2192 



/Michael J. Yigdall/ 

Primary Examiner, Art Unit 2192 



